DEV Community: Diego Carreira de França

Beyond Create React App: A Comprehensive Comparison of Modern Build Tools

Diego Carreira de França — Tue, 08 Apr 2025 13:16:07 +0000

Introduction

With Create React App (CRA) now in maintenance mode, developers are being pushed towards alternative build tools for their React applications (Good!!! I dare to say, since there are better options out there!).

This article compares some of the most popular alternatives, helping you make an informed decision for your next project.

The Main Contenders

1. Vite

Vite has emerged as one of the most popular alternatives to CRA, offering lightning-fast development experience.

# Quick project setup
npm create vite@latest my-react-app -- --template react
# Quick project setup with TypeScript
npm create vite@latest my-react-app -- --template react-ts

Pros:

Extremely fast development server startup
Hot Module Replacement (HMR) that actually works
Built-in TypeScript support
Minimal configuration required

Cons:

Younger ecosystem compared to Webpack
Some plugins might not be available for some specfic cases
Production builds might require additional configuration

2. Webpack

The tried-and-tested bundler that powered CRA.

# Instalation
npm install webpack webpack-cli --save-dev

// webpack.config.js
module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        use: 'babel-loader',
      },
    ],
  },
}

Pros:

Mature ecosystem
Highly configurable
Extensive plugin system
Battle-tested in production

Cons:

Slower development server startup
Complex configuration
Steeper learning curve

3. Next.js

More than just a build tool, Next.js is a full-featured React framework.

# Create a new Next.js project
npx create-next-app@latest

Pros:

Built-in routing system
Server-side rendering (SSR)
Automatic code splitting
Zero configuration
Great developer experience

Cons:

Might be overkill for simple SPAs
Opinionated structure
Locked into Vercel ecosystem (not required, but you might have a little pain setting up to deploy in other platforms)

4. Parcel

The zero-configuration bundler alternative.

# Install Parcel
npm install --save-dev parcel

Pros:

Zero configuration
Fast builds
Built-in support for various file types
Simple to use

Cons:

Less flexible than Webpack
Smaller ecosystem
Limited advanced features

Performance Comparison

Development Server Startup Time:

Vite: < 1 second
Webpack: 5–10 seconds
Next.js: 2–3 seconds
Parcel: 2–4 seconds

Build Time (Production):

Vite: ~20 seconds
Webpack: ~40 seconds
Next.js: ~25 seconds
Parcel: ~30 seconds

Setting Up a React Project with Each Tool

Vite Setup

# Create project
npm create vite@latest my-app -- --template react

# Install dependencies
cd my-app
npm install

# Start development server
npm run dev

Webpack Setup

# Create project directory
mkdir my-webpack-react
cd my-webpack-react

# Initialize package.json
npm init -y

# Install dependencies
npm install react react-dom
npm install --save-dev webpack webpack-cli babel-loader @babel/core @babel/preset-react

# Create webpack.config.js
# (Configuration as shown above)

Next.js Setup

# Create project
npx create-next-app@latest

# Start development server
npm run dev

Feature Comparison Matrix

Feature	Vite	Webpack	Next.js	Parcel
Fast Dev	✅	❌	⚠️	⚠️
Zero Config	⚠️	❌	✅	✅
SSR Support	❌	⚠️	✅	❌
TypeScript	✅	⚠️	✅	✅
Plugin Ecosystem	⚠️	✅	⚠️	⚠️

Making the Right Choice

Choose Vite if:

You want fast development experience
You're building a modern SPA
You want minimal configuration

Choose Webpack if:

You need maximum flexibility
You have specific build requirements
You're working with legacy code

Choose Next.js if:

You need SSR/SSG
You want a full-featured framework
You want built-in routing and need API routes

Choose Parcel if:

You want zero configuration
You're building a simple application
You need quick setup

Best Practices

Start with the simplest tool that meets your requirements
Consider your team's expertise
Evaluate build performance requirements
Check community support and documentation
Consider long-term maintenance

Conclusion

While each tool has its strengths, Vite and Next.js stand out as the most compelling alternatives to CRA at the moment. Vite offers an excellent development experience for SPAs, while Next.js provides a complete framework solution. Choose based on your specific project needs and team expertise.

Next Steps

Try building a small project with each tool to gain deeper understanding of each
Review the migration guides from CRA (click here to see the oficial page)
Explore the ecosystem of your chosen tool

Thoughts ?

🚨 Why Accessibility Isn’t Optional – A Frontend Dev’s Responsibility 🚨

Diego Carreira de França — Mon, 07 Apr 2025 23:25:15 +0000

As frontend developers, we don’t just build interfaces – we build experiences for everyone. Yet, accessibility (a11y) is often treated as an afterthought. Let’s change that.

Why it matters:

1 in 6 people globally live with disabilities (WHO).
Legal risks: Lawsuits like Domino’s vs. Guillermo set precedents.
Ethically, it’s the right thing to do.
Practically, accessible sites rank better, reach more users, and future-proof your work.

Here’s how I prioritize accessibility in React projects:

1. Semantic HTML + ARIA Roles

Avoid <div> soup! Use native elements like <button>, <nav>, and <main>. When necessary, enhance with ARIA:

// ❌ Bad: Generic div as a button  
<div onClick={handleClick}>Submit</div>

// ✅ Good: Semantic + ARIA  
<button 
  onClick={handleClick}
  aria-label="Submit form"
  role="button" // Redundant here, but useful for custom components
>
  Submit
</button>

2. Keyboard Navigation & Focus Management

Ensure all interactive elements are keyboard-friendly. Use tabIndex and :focus-visible:

// Custom component with keyboard support  
const CustomButton = ({ onClick, children }) => {
  const handleKeyPress = (e) => {
    if (e.key === 'Enter' || e.key === ' ') onClick();
  };

  return (
    <div
      role="button"
      tabIndex={0}
      onClick={onClick}
      onKeyPress={handleKeyPress}
      className="custom-btn"
    >
      {children}
    </div>
  );
};

3. Accessible Forms with Labels

Never skip <label> or use placeholder text as a label:

// ❌ Bad: Placeholder as label  
<input type="text" placeholder="Enter email" />

// ✅ Good: Proper labeling  
<label htmlFor="email">Email Address</label>
<input 
  type="email" 
  id="email" 
  name="email" 
  aria-describedby="email-help" 
/>
<p id="email-help">We’ll never share your email.</p>

4. Contrast Ratios & Responsive Design

Use tools like WebAIM Contrast Checker to meet WCAG standards. Avoid tiny click targets!

5. Test with Screen Readers & Tools

Lighthouse Audit: Run audits in Chrome DevTools.
axe DevTools: Automated accessibility testing.
NVDA/JAWS: Test with actual screen readers if you can.

6. What about Mobile ?

Accessibility is non-negotiable, whether you’re building for web or mobile. In React Native, small tweaks can make your app usable for everyone. Here’s how:

A). Label Images and Icons

Screen readers rely on accessibilityLabel to describe visual elements:

<Image
  accessibilityLabel="Men wearing hat, glasses, and a headset"
  accessibilityRole="image"
  source={{ uri: 'https://images.unsplash.com/photo-1509098681029-b45e9c845022?q=80&w=240&auto=format' }}
  style={styles.avatar}
  width={200}
  height={200}
/>

Why it matters: Without labels, screen readers might say "unlabeled image" or skip the element entirely.

B). Use `accessibilityRole` for Clarity

Define the purpose of interactive elements:

<TouchableOpacity
  accessibilityLabel="Submit form"
  accessibilityRole="button" // Tells screen readers this is clickable
  onPress={handleSubmit}
>
  <Text>Submit</Text>
</TouchableOpacity>

C). Add `accessibilityHint` for Complex Actions

Provide extra context where needed:

<Button
  accessibilityLabel="Delete account"
  accessibilityHint="Double-tap to permanently delete your account"
  onPress={confirmDelete}
/>

D). Test with VoiceOver/TalkBack

iOS: Enable VoiceOver in Settings > Accessibility.
Android: Enable TalkBack in Accessibility settings.
Pro Tip: Use accessibilityLiveRegion for dynamic content (e.g., loading states):

  <Text accessibilityLiveRegion="polite">{loading ? 'Loading...' : 'Success!'}</Text>

🔗 Resources:

React Native Accessibility Docs: https://reactnative.dev/docs/accessibility
WCAG Guidelines: https://www.w3.org/WAI/standards-guidelines/wcag/

Accessibility isn’t optional – it’s the baseline.
By adding it to our workflows, we create inclusive, future-proof products.

Thoughts ?

🧪 React Testing: Tips That Actually Work

Diego Carreira de França — Wed, 19 Mar 2025 21:06:20 +0000

1. Test What Users See, Not What Developers Write

// 👎 Don't do this
test('component sets loading state', () => {
  const wrapper = shallow(<UserProfile />);
  expect(wrapper.state('isLoading')).toBe(true);
});

// 👍 Do this instead
test('shows loading state to users', () => {
  render(<UserProfile />);
  expect(screen.getByText('Loading...')).toBeInTheDocument();
});

2. Smart Ways to Test User Actions

// 👎 Testing implementation details
test('updates email state', () => {
  const wrapper = shallow(<SignupForm />);
  wrapper.find('input').simulate('change');
  expect(wrapper.state('email')).toBe('test@email.com');
});

// 👍 Testing user behavior
test('lets user submit their email', () => {
  const handleSubmit = jest.fn();
  render(<SignupForm onSubmit={handleSubmit} />);

  // Type like a real user would
  userEvent.type(
    screen.getByRole('textbox', { name: /email/i }), 
    'test@email.com'
  );

  // Click like a real user would
  userEvent.click(screen.getByRole('button', { name: /submit/i }));

  expect(handleSubmit).toHaveBeenCalledWith('test@email.com');
});

3. Stop Mocking Everything

// 👎 Over-mocking
jest.mock('./UserAvatar');
jest.mock('./UserBio');
jest.mock('./UserStats');

// 👍 Only mock what's necessary (like APIs)
const server = setupMSW([
  rest.get('/api/user', (req, res, ctx) => {
    return res(ctx.json({ name: 'John' }))
  })
]);

4. Testing Hooks? Keep It Simple

// 👎 Complex setup
const wrapper = mount(
  <Provider store={store}>
    <ThemeProvider theme={theme}>
      <HookComponent />
    </ThemeProvider>
  </Provider>
);

// 👍 Just test the logic
const { result } = renderHook(() => useCounter());
act(() => {
  result.current.increment();
});
expect(result.current.count).toBe(1);

5. Write Fewer, Better Tests (Meaningful tests)

// 👎 Testing every little thing
test('renders header');
test('renders subheader');
test('renders each list item');
test('renders footer');

// 👍 Test important flows
test('lets user complete checkout flow', async () => {
  render(<CheckoutFlow />);

  await userEvent.type(screen.getByLabelText(/card/i), '4242...');
  await userEvent.click(screen.getByText(/pay/i));

  expect(screen.getByText(/thanks for your order/i)).toBeInTheDocument();
});

6. Smart Selectors

// 👎 easy-to-break selectors
getByTestId('submit-button')
querySelector('.submit-btn')

// 👍 Resilient selectors
getByRole('button', { name: /submit/i })
getByLabelText(/email/i)
getByText(/welcome/i)

7. Testing Loading States

// 👍 Handle common async patterns
test('shows loading and then content', async () => {
  render(<UserProfile />);

  // Check loading state
  expect(screen.getByText(/loading/i)).toBeInTheDocument();

  // Wait for data
  await screen.findByText('John Doe');

  // Loading should be gone
  expect(screen.queryByText(/loading/i)).not.toBeInTheDocument();
});

8. Test Error States

// 👍 Don't forget error handling
test('handles API errors gracefully', async () => {
  server.use(
    rest.get('/api/user', (req, res, ctx) => {
      return res(ctx.status(500))
    })
  );

  render(<UserProfile />);

  await screen.findByText(/something went wrong/i);
  expect(screen.getByRole('button', { name: /try again/i })).toBeInTheDocument();
});

🎯 Quick Checklist Before Pushing

✅ Tests pass
✅ Tests are meaningful
✅ Used realistic user interactions
✅ Focused on behavior intead of implementation
✅ Covered error states
✅ Used resilient selectors
✅ Mocked only what's necessary

💡 Remember

Tests should give you confidence to refactor
If tests break when you refactor (but the app works), your tests are wrong
Test behavior, not implementation
When in doubt, test like a user

🤖 Should I Use AI for Code Reviews? 🤔

Diego Carreira de França — Tue, 11 Mar 2025 18:53:57 +0000

Hey! Let's cut to the chase - you're probably wondering if AI code review tools are worth your time. Let's look at real examples where they shine (and where they don't).

Where AI Actually Helps 👍

1. Catching Simple But Annoying Mistakes

// Your code
function getUserData(id) {
  const user = users.find(u => u.id === id);
  return user.data;  // Potential null reference
}

// AI suggestion: "Hey, you might want to add a null check here"
function getUserData(id) {
  const user = users.find(u => u.id === id);
  return user?.data ?? null;
}

2. Style and Best Practices

// Your code
const processItems = (items) => {
  let result = [];
  for(let i = 0; i < items.length; i++) {
    result.push(items[i].value * 2);
  }
  return result;
}

// AI suggestion: "This could be simpler with map()"
const processItems = (items) => 
  items.map(item => item.value * 2);

3. Performance Hints

// Your code
const searchUsers = users.filter(user => {
  return user.name.toLowerCase().includes(searchTerm.toLowerCase());
}).map(user => user.name);

// AI suggestion: "Moving toLowerCase() outside the loop"
const searchTermLower = searchTerm.toLowerCase();
const searchUsers = users
  .filter(user => user.name.toLowerCase().includes(searchTermLower))
  .map(user => user.name);

Where AI Falls Short 👎

1. Business Logic

// AI won't understand your business rules
function calculateDiscount(user, cart) {
  // Complex business logic here
  if (user.tier === 'premium' && cart.total > 100) {
    return cart.total * 0.15;
  }
  // AI might suggest "simplifying" this,
  // but it doesn't know your business rules!
}

2. Architecture Decisions

// AI won't help much with architectural choices
// It might even give bad advice!
import { useContext } from 'react';

// AI might not understand why you chose
// Context over Props or Redux
const UserProfile = () => {
  const user = useContext(UserContext);
  // ...
}

The Bottom Line 🎯

✅ Use AI review tools for:

Catching typos and basic errors
Style consistency
Simple refactoring suggestions
Security basics

❌ Don't rely on AI for:

Business logic validation
Architecture decisions
Complex security reviews
Team-specific patterns

Quick Start (if you want to try)

# Most IDEs now have AI integration
# VSCode + GitHub Copilot example:
1. Install GitHub Copilot extension
2. Open a PR
3. Look for the AI suggestions in comments

# That's it! Start small and see if it helps

Pro Tip 💡

Use AI reviews as a first pass before human review. It's like having a junior dev look at your code before your senior dev does - helpful, but not the final word.

Remember: AI is a tool, not a replacement for thinking! 🧠

Thanks for reading! Do you have any thoughts ? Leave questions or comments below.

DEV Community: Diego Carreira de França

Beyond Create React App: A Comprehensive Comparison of Modern Build Tools

Introduction

The Main Contenders

1. Vite

2. Webpack

3. Next.js

4. Parcel

Performance Comparison

Setting Up a React Project with Each Tool

Vite Setup

Webpack Setup

Next.js Setup

Feature Comparison Matrix

Making the Right Choice

Best Practices

Conclusion

Next Steps

🚨 Why Accessibility Isn’t Optional – A Frontend Dev’s Responsibility 🚨

1. Semantic HTML + ARIA Roles

2. Keyboard Navigation & Focus Management

3. Accessible Forms with Labels

4. Contrast Ratios & Responsive Design

5. Test with Screen Readers & Tools

6. What about Mobile ?

A). Label Images and Icons

B). Use accessibilityRole for Clarity

C). Add accessibilityHint for Complex Actions

D). Test with VoiceOver/TalkBack

🧪 React Testing: Tips That Actually Work

1. Test What Users See, Not What Developers Write

2. Smart Ways to Test User Actions

3. Stop Mocking Everything

4. Testing Hooks? Keep It Simple

5. Write Fewer, Better Tests (Meaningful tests)

6. Smart Selectors

7. Testing Loading States

8. Test Error States

🎯 Quick Checklist Before Pushing

💡 Remember

🤖 Should I Use AI for Code Reviews? 🤔

Where AI Actually Helps 👍

1. Catching Simple But Annoying Mistakes

2. Style and Best Practices

3. Performance Hints

Where AI Falls Short 👎

1. Business Logic

2. Architecture Decisions

The Bottom Line 🎯

Quick Start (if you want to try)

Pro Tip 💡

B). Use `accessibilityRole` for Clarity

C). Add `accessibilityHint` for Complex Actions